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Media Server Control Protocol Reguirements 
Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


This document addresses the communication between an application 
server and media server. The current work in IETF working groups 
shows these logical entities, but it does not address the physical 
decomposition and the protocol between the entities. 


This document presents the requirements for a Media Server Control 
Protocol (MCP) that enables an application server to use a media 
server. It will address the aspects of announcements, Interactive 
Voice Response, and conferencing media services. 
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Introduction 


The IETF conferencing framework in RFC 4353 [CARCH] presents an 
architecture that is built of several functional entities. RFC 4353 
[CARCH] does not specify the protocols between the functional 
entities since it is considered out of scope. 


Based on RFC 4353 [CARCH], this document defines the requirements for 
a protocol that will enable one functional entity, known as an 
Application Server (AS), that includes the conference/media policy 
server, the notification server, and the focus, all defined in RFC 
4353 [CARCH], to interact with one or more functional entities, 
called Media Server (MS), that serves as mixer or media server. 


The media server can also be used for announcements and Interactive 
Voice Response (IVR) functions. 


Application servers host one or more instances of a communication 
application. Media servers provide real time media processing 
functions. An example of the decomposition of a media server and an 
application server is described in the media control framework 
document [MEDIACTRL-FW]. 


This document presents the requirements for a Media Server Control 
Protocol (MCP) that enables an application server to control a media 
server. It will address the aspects of announcements, IVR, and 
conferencing media services. 


The reguirements are for the protocol and do not address the AS or MS 
functionality discussed in the media control framework. 


Since the media server is a centralized component, the charter of the 
working group states that this work will not investigate distributed 
media processing algorithms or control protocols. 


Terminology 


The media server work uses, when appropriate, and expands on the 
terminology introduced in the conferencing framework [CARCH] and 
Centralized Conferencing (XCON) framework [XCON-FRMWRK]. The 
following additional terms are defined: 


Application Server (AS) - A functional entity that hosts one or more 
instances of a communication application. The application server may 
include the conference policy server, the focus, and the conference 
notification server, as defined in [CARCH]. Also, it may include 
communication applications that use IVR or announcement services. 
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Media Server (MS) - The media server includes the mixer as defined in 
[CARCH]. The media server plays announcements, it processes media 
streams for functions like Dual Tone Multi-Frequency (DTMF) detection 
and transcoding. The media server may also record media streams for 
supporting IVR functions like announcing participants 


Media Resource Broker (MRB) - A logical entity that is responsible 
for both the collection of appropriate published Media Server (MS) 
information and supplying of appropriate MS information to consuming 
entities. The MRB is an optional entity and will be discussed in a 
separate document. 


Notification - A notification is used when there is a need to report 
event-related information from the MS to the AS. 


Request - A request is sent from the controlling entity, such as an 
application server, to another resource, such as a media server, 


asking that a particular type of operation be executed. 


Response - A response is used to signal information, such as an 
acknowledgement or error code in reply to a previously issued 
reguest. 


Requirements 
1. Media Control Requirements 
The following are the media control requirements: 
REO-MCP-01 - The MS Control Protocol shall enable one or more 


application servers to reguest media services from one or more 
media servers. 


REO-MCP-02 - The MS Control Protocol shall use a reliable transport 
protocol. 

REO-MCP-03 - The applications supported by the protocol shall 
include conferencing and Interactive Voice Response media 
services. 


Note: Though the protocol enables these services, the functionality 
is invoked through other mechanisms. 


REO-MCP-04 - Media types supported in the context of the 
applications shall include audio, tones, text, and video. Tones 
media include in-band audio or RFC 4733 payload. 
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REO-MCP-05 - The MS control protocol should allow, but must not 
reguire, a media resource broker (MRB) or intermediate proxy to 
exist with the application server and media server. 


REO-MCP-06 - On the MS control channel, there shall be reguests to 
the MS, responses from the MS, and notifications to the AS. 


REO-MCP-07 - SIP/SDP (Session Initiation Protocol / Session 
Description Protocol) shall be used to establish and modify media 
connections to a media server. 


REO-MCP-08 - It should be possible to support a single conference 
spanning multiple media servers. 


Note: It is probable that spanning multiple MSs can be 
accomplished by the AS and does not require anything in the 
protocol for the scenarios we have in mind. However, the concern 
is that if this reguirement is treated too lightly, one may end up 
with a protocol that precludes its support. 


REO-MCP-09 - It must be possible to split call legs individually, or 
in groups, away from a main conference on a given media server, 
without performing re-establishment of the call legs to the MS 
(e.g., for purposes such as performing IVR with a single call leg 
or creating sub-conferences, not for creating entirely new 
conferences). 


REO-MCP-10 - The MS control protocol should be extendable, 
facilitating forward and backward compatibility. 


REO-MCP-11 - The MS control protocol shall include an authentication 
component to ensure that only an authorized AS can communicate 
with the MS, and vice versa. 


REO-MCP-12 - The MS control protocol shall use some form of 
transport protection to ensure the confidentiality and integrity 
of the data between the AS and MS. 


REO-MCP-13 - Different application servers may have different 
privileges for using an MS. The protocol should prevent the AS 
from doing unauthorized operations on a MS. 


REO-MCP-14 - The MS control protocol reguires mechanisms to protect 


the MS resources used by one AS from another AS since the solution 
needs to support multiple ASs controlling one MS. 
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REO-MCP-15 - During session establishment, there shall be a 
capability to negotiate parameters that are associated with media 
streams. This reguirement should also enable an AS managing 


conference to specify the media streams allowed in the conference. 


REO-MCP-16 - The AS shall be able to instruct the MS to perform 
stream operations like mute and gain control. 


REO-MCP-17 - The AS shall be able to instruct the MS to play a 
specific announcement. 


REO-MCP-18 - The AS shall be able to request the MS to create, 
delete, and manipulate a mixing, IVR, or announcement session. 


REO-MCP-19 - The AS shall be able to instruct the MS to play 
announcements to a single user or to a conference mix. 


REO-MCP-20 - The MS control protocol should enable the AS to ask the 
MS for a session summary report. The report may include resource 
usage and guality metrics. 


REO-MCP-21 - The MS shall be able to notify the AS of events 
received in the media stream if reguested by the AS. (Examples - 
STUN reguest, Flow Control, etc.) 


3.2. Media mixing Reguirements 


REO-MCP-22 - The AS shall be able to define a conference mix; the MS 
may offer different mixing topologies. The conference mix may be 
defined on a conference or user level. 


REO-MCP-23 - The AS may be able to define a custom video layout 
built of rectangular sub-windows. 


REO-MCP-24 - For video, the AS shall be able to map a stream to a 
specific sub-window or to define to the MS how to decide which 
stream will go to each sub-window. 


REO-MCP-25 - The MS shall be able to notify the ASs of who the 
active sources of the media are; for example, who the active 
speaker is or who is being viewed in a conference. The speaker 
and the video source may be different, for example, a person 
describing a video stream from a remote camera managed by a 
different user. 


Dolly & Even Informational [Page 5] 


RFC 5167 MCP Reguirements March 2008 


REO-MCP-26 - The MS shall be able to inform the AS which layouts it 
supports. 
REO-MCP-27 - The MS control protocol should enable the AS to 


instruct the MS to record a specific conference mix. 
3.3. IVR Requirements 
REO-MCP-28 - The AS shall be able to instruct the MS to perform one 


or more IVR scripts and receive the results. The script may be in 
a server or contained in the control message. 


REO-MCP-29 - The AS shall be able to manage the IVR session by 
sending requests to play announcements to the MS and receiving the 
response (e.g., DTMF). The IVR session flow, in this case, is 


handled by the AS by starting a next phase based on the response 
it receives from the MS on the current phase. 


REO-MCP-30 - The AS should be able to instruct the MS to record a 
short participant stream and play it back. This is not a 
recording reguirement. 


3.4. Operational Requirements 


These requirements may be applicable to the MRB, but they can be used 
by an AS if it has a one-to-one connection to the MS. 


REO-MCP-31 - The MS control protocol must allow the AS to audit the 
MS state during an active session. 


REO-MCP-32 - The MS shall be able to inform the AS about its status 
during an active session. 


4. Security Considerations 


This document discusses high-level reguirements for MCP. The MCP has 
some specific security reguirements, which will be summarized here at 
a very high level. 


All of the operations and functions described in this document need 
to be authorized by an MS or an AS. It is expected that MS resources 
will be governed by a set of authorization rules defined as part of 
the AS / MS policy. In order for the policy to be implemented, the 
MS needs to be able to authenticate reguests. Normal SIP mechanisms, 
including Digest authentication and certificates, can be used as 
specified in RFC 3261 [RFC3261]. These MCP security reguirements 
will be discussed in detail in the framework and protocol documents. 
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